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A SYSTEM AND METHOD FOR EXCHANGING DATA AND COMMANDS 
BETWEEN AN OBTECT ORIENTED SYSTEM AND A RELATIONAL SYSTEM 



3 Inventor: . Damodar D. Periwal , ( 

4 J BACKGROUND OF THE INVENTION 

5 1. Field of the Invention . 

6 The present invention relates generally to systems and methods for transferring 

7 data and commands between computing systems. In particular, the present invention 

8 relates to a system and a method for exchanging data and commands between an object 
: p 9 oriented system and a relational system. 

^10 2. Description of the Background Art . 

With the development and proliferation of computers of increasing performance 

□ 

LJ12 capability, a number of different languages and programming paradigms have been 



^fl3 developed. These languages and programming paradigms are used in conjunction with 

14 data that can be stored persistently in a variety of different ways. For example, options 

15 for persistent storage include relational databases, file systems and object-oriented 

16 databases. 

17 Most data has been stored in a relational format such as in tables of a relational 

18 database. The data is manipulated and maintained by a relational database 

19 management system (RDBMS). One particularly attractive attribute of such relational 

20 systems is that RDBMSs are able to persistently store data. Relational systems are 
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1 persistent in the sense that the data is stored in a stable storage environment such that 

2 the data is accessible even after the application that created the original data stops 

3 executing. Furthermore, there are a number of applications and tools available for the 

4 manipulation and maintenance of such data in relational databases. Since relational 

5 databases have been in existence for many years, the use and proliferation of such 

6 applications and tools are widespread, and sophistication and capabilities of the tools 

7 are great. 

8 However, a new programming paradigm that has become more widespread in 

9 recent years is object-oriented programming (OOP). In fact, OOP is becoming the 
'f:?10 dominant programming paradigm with the development and widespread use of new 
ijill programming languages such as JAVA and C++. In OOP, a class is used to encapsulate 
' - Jl2 the structure and behavior of objects. Thus, the objects contain both the data and the 

functionality for manipulation of the data. 

B . 3 

[1jl4 It is very natural and desirable for application developers to represent the 

U3l5 business objects in an object-oriented language like Java and at the same time use 
03 

16 RDBMS for the persistence storage of those objects. 

17 One problem existing in the art is that there are no systems and methods to 

18 bridge the gap between the programming paradigm used for object-oriented systems 

19 and the programming paradigm used for relational systems. There are also no systems 

20 and methods for bridging the gap between the languages used for object-oriented 

21 systems such as Java and the languages used in relational systems such as SQL. 

22 Furthermore, there is no easy method for specifying the mapping between such object- 
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1 oriented systems and relational systems. Thus, to perform translation between these 

2 systems has required hand coding of the mapping between object-oriented systems and 

3 relational systems, and hand coding is tedious, time-consuming, error-prone and tends 

4 to be non-uniform. Therefore, there is a need for systems and method for automatically 

5 translating and exchanging data between object-oriented systems and relational 

6 systems. 

7 The prior art has attempted to solve the problem with graphical user interfaces 

8 that define mappings and by producing proprietary platform specific code that will 

9 translate between object-oriented systems and relational systems. However, such prior 

ill 

J-IO art systems have the following shortcomings. First, they are not always able to create a 

fjlll relational schema given an object model. Second, they are not always able to produce 

Hi 

"^12 an object model given a relational schema. Third, they do not provide a uniform 

]^13 method for specifying directed options for object graph specification for different 

I1jl4 operations. Fourth, the prior art is not able to handle large sets of queried objects by 

^3l5 streaming them between different tiers of applications. Thus, they are subject to 

16 memory bandwidth and response-time performance problems. Finally, such existing 

17 systems are coded for operation with a particular RDBMS. Thus, they are not 

18 interoperable among different relational back ends. 

19 In object-oriented systems, when a new object is created it is typically assigned 

20 an identification number that can identify it uniquely among other objects of the same 

21 type. If objects are stored persistently in a database, the identification number assigned 

22 to a newly created object in memory should be unique with respect to even the already 
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1 stored objects in the database. So there is a need for a system and method having the 

2 ability to always provide a unique number. The existing art has attempted to solve the 

3 problem of providing unique identification numbers by providing the notion of a 

4 unique row-id in the RDBMS, thereby assigning a newly inserted row a unique number. 

5 However, the prior art approach has a number of disadvantages. First, the unique id is 

6 not known to the program until the object is inserted in the database. So if the 

7 programmer has to create related objects which need to know the unique ids for their 

8 initialization, the current scheme would require an insert operation and then a query 

9 operation to get the RDBMS assigned unique id. This is inefficient and cumbersome. 
j« 10 Second, not all RDBMSs have the feature of unique row-ids, thus, such systems in the 
ijill prior art cannot generate unique ids. Third, each RDBMS specifies its own unique way 

l 'i i 
h : 

^12 of defining and retrieving these row ids. So the application programmer cannot use a 

^13 consistent and portable way of defining, using and referring to the unique ids. 

Ui 

FU14 Therefore, because of the advantages offered by OOP and the persistence of data 

s . ; 

^15 offered by relational systems there is a need for a system that can easily be configured 

16 and that can reliably and automatically transfer data between such relational systems 

17 and object-oriented systems. 
18 

19 SUMMARY OF THE INVENTION 

20 The present invention overcomes the deficiencies and limitations of the prior art 

21 with a system and methods for exchanging data and commands between an object 

22 oriented system and a relational system. In particular, the system of the present 
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1 invention comprises an Object-Relational Mapping (ORM) grammar, an ORM 

2 specification, Object Class Definitions, a relational database, an operating system, a 

3 Database Exchange Unit including an OR mapping unit, a schema generator, a schema 

4 reverse engineering unit and applications. The ORM specification is based on the ORM 

5 grammar and includes information for defining the mapping between the object- 

6 oriented system and the relational system. The Object Class Definitions define the 

7 object-oriented system, and the relational database defines the relational system. The 

8 Database Exchange Unit executes in accordance with the ORM specification, and is the 

9 programs/ routines that operate to translate data from the object model to the relational 

f § 

^10 model, and vice versa. The schema reverse engineering unit creates Object Class 

Hill Definitions and an ORM specification from an ORM template specification and 

]f 12 database schema. The schema generator generates the RDBMS schema from Object 
Class Definitions and the ORM specification. The system and method of the present 

yj 

fli 14 invention are particularly advantageous due to an innovative grammar used to define 

;f:f 15 the mapping between an object-oriented system and a relational system. The 

16 specification of mapping information using this innovative grammar allows the 

17 mapping information to be stored conveniently and easily in an operating system file 

18 and also as part of the relational database. The present invention also provides an 

19 application programming interface (API) that automates the tedious object-oriented 

20 program translation code between the relational system and the object oriented system. 

21 Furthermore, the system and methods of the present invention include units to provide 

22 for the automatic, sequenced number generation for new objects. This is advantageous 
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1 because it provides user flexibility in naming object identifiers for persistent storage in 

2 the database while ensuring that the object identifiers are unique. 

3 The present invention further comprises a number of methods including: a 

4 method for generating a ORM Data Structure; a method for generating a mapping unit; 

5 a method for generating a schema from an object model and an object-relational 

6 mapping specification; a method for generating Object Class Definitions and an ORM 

7 specification from an ORM template specification and database schema; and a method 

8 for object streaming. 



8 9 



|l0 BRIEF DESCRIPTION OF THE DRAWINGS 

S * 

sjll Figure 1 is a block diagram of a first and preferred embodiment for a system 

= 12 constructed according to a preferred embodiment of the present invention for object- 

=/Jl3 relational mapping. 

•, - 

yl4 Figure 2 is a block diagram of a first and preferred embodiment of a memory 

15 used in the system of Figure 1, and including the present invention. 

16 Figure 3 is a block diagram of a second embodiment of the system of the present 

17 invention illustrating the present invention implemented as modules. 

18 Figure 4 is a block diagram of a first embodiment of a Database Exchange Unit of 

19 Figure 2 as routines stored in the memory of the system. 

20 Figure 5 is a block diagram of a second embodiment of the Database Exchange 

21 Unit constructed as modules. 
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1 Figure 6 is a block diagram of a first embodiment of a schema generator of Figure 

2 2 as routines stored in the memory of the system. 

3 Figure 7 is a block diagram of a second embodiment of the schema generator 

4 constructed as modules. 

5 Figure 8 is a block diagram of a first embodiment of a schema reverse 

6 engineering unit of Figure 2 as routines stored in the memory of the system. 

7 Figure 9 is a block diagram of a second embodiment of the schema reverse 

8 engineering unit constructed as modules. 

9 Figure 10 is a flowchart of the preferred process for generating an ORM Data 
Structure according to the present invention from an ORMID or ORM file; 

c 

ulll Figure 11 is a flowchart of the preferred process for generating ORM Data 

"212 Structures according to the present invention using an ORM specification; 

r]13 Figure 12 is a flowchart of the preferred process for generating relational schema 

y 

rJl4 from an ORM specification and Object Class Definitions. 

^15 Figure 13 is a flowchart of the preferred process for generating an ORM 

16 specification and Object Class Definitions from a database schema. 

17 Figures 14A and 14B are a flowchart of the preferred process for responding to 

18 an object call using a mapping unit generated from an ORM specification. 

19 Figure 15 is a flowchart of the preferred process for object streaming. 

20 Figure 16 is a flowchart of the preferred process for generating foreign key 

21 entries and associating them according to a plan data structure set up as per directed 

22 query options. 
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1 Figure 17 is the specification of an exemplary ORM grammar used in the present 

2 invention. 

3 Figure 18 is a textual representation of an exemplary ORM specification; 

4 Figure 19 is a graphical representation of the exemplary ORM specification of 

5 Figure 17 showing the mappings between the object model and the relational model 

6 that will be performed by a database exchange using the exemplary ORM specification. 

7 Figures 20A-20D are block diagrams of architectural configurations of the 

8 present invention in different tiers (parts) of applications using different relational 

9 database management systems. 

10 Figures 21 A-21B are graphic block diagrams of architectural configurations 

11 without and with the present invention. 

12 Figures 22A and 22B are flowcharts of the preferred process for generating 



13 Named Sequence Generators and using them to produce persistent object identification 

14 numbers. 
15 

16 



17 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

18 Referring now to Figure 1, a block diagram of a preferred embodiment of an 

19 object-relational mapping system 100 constructed in accordance with the present 

20 invention is shown. The object-relational mapping system 100 preferably comprises a 

21 central processing unit or processor 102 that connects with a memory 104, an input 

22 device 106, an output or display device 108, a data storage device 110, and a network 
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1 interface 112. The processor 102, memory 104, input device 106, output device 108, 

2 storage device 110, and network interface 112 are preferably coupled in a von Neuman 

3 architecture via a bus 114 such as a personal or mini computer. The processor 102 is 

4 preferably a microprocessor such as a Sun Sparc, PowerPC or an Intel Pentium; the 

5 output device 108 is preferably a video monitor; and the input device 106 is preferably a 

6 keyboard and mouse- type controller. The memory 104 is preferably random access 

7 memory (RAM) and read-only memory (ROM). The processor 102 is also coupled to 

8 the network interface 112 in a conventional manner for connection to a network via line 

9 116 and other computers such as via a local area network, wide area network or the 
^10 Internet. In an exemplary embodiment, the object-relational mapping system 100 

operates on an IBM-type personal computer. Those skilled in the art will realize that 

"if 12 the object-relational mapping system 100 could also be implemented as any one of a 

pl3 variety of other computers such as those made by Apple, Sun, Digital Equipment 

M 

I)jl4 Corporation or IBM. 

y 

JfflS The object-relational mapping system 100 of the present invention provides for 

16 the automatic and systematic exchange of data and commands between an object- 

17 oriented system and a relational system. The processor 102, under the guidance of 

18 instructions received from the memory 104 and from the user through the input device 

19 106, provides signals for the exchange of data and commands between an object- 

20 oriented system and a relational system. The memory 104 preferably includes an ORM 

21 Grammar 200, an ORM Specification 202, Object Class Definitions 204, a relational 

22 database management system (RDBMS) 206, an operating system 208, a Database 
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1 Exchange Unit 210, a schema generator 212, RDBMS tables and ORMMetadata Tables 

2 214, applications 216, a GUI or text editor 218, a schema reverse-engineering unit 220, 

3 an ORM template specification 222, a Metadata ORM specification 224, and Named 

4 Sequence Generators 226. The operation interaction of the above modules of the 

5 present invention provides for the automatic, systematic exchange of data between an 

6 object- oriented system and a relational system. In particular, the present invention 

7 with the above modules allows for: 1) the generation of modules (ORM Data Structure) 

8 for translation of data from an objectoriented system to a relational system based on an 

^ 9 ORM specification; 2) the generation of an ORM specification and an Object Class 

O 

i'JlO Definitions from a database schema; 3) the generation of a relational schema from an 

0*11 ORM Specification and Object Class Definitions; and 4) the transfer of data between the 

^12 object-oriented system and the relational system. Those skilled in the art will realize 

pl3 that various equivalent combinations of devices can achieve the same results when used 

Pji4 in accordance with the present invention. For example, while the memory blocks 200, 
W 

$15 202, 204, 206, 208, 210, 212, 214, 216, 218, 220, 222, 224 and 226 are shown as separate, 

16 units and coupled to each other and other components by the bus 114, they can easily 

17 comprise different regions of a contiguous space in memory. While the memory blocks 

18 200, 202, 204, 206, 208, 210, 212, 214, 216, 218, 220, 222, 224 and 226 will now be 

19 described as routines or modules, and therefore primarily defined by their 

20 functionality, those skilled in the art will recognize that the particular modules or 

21 portions could be implemented in hardware as an alternate embodiment. 



PATENT 



1 The system and methods of the present invention are particularly advantageous 

2 because of the use of an innovative ORM Grammar 200 to define the mapping between 

3 an object-oriented system and a relational system. Such an exemplary grammar is 

4 shown in Figure 17. Furthermore, Appendix A provides more detail on the ORM 

5 Grammar 200 including the syntax, an explanation and an example. The ORM 

6 Grammar 200 the rules for textually describing an Object-Relational Mapping (ORM) in 

7 a declarative way. The specification of mapping information using this innovative 

8 Grammar 200 allows the mapping information to be stored conveniently and easily in 

9 an operating system file and also as part of the relational database, as will be discussed 

Li 

a Si 

^10 in more detail below with reference to Figure 10. This ORM Grammar 200 is shown in 

ylll detail in Figure 17. While the ORM Grammar 200 is shown as being stored in memory, 

^12 the ORM Grammar 200 may in alternate embodiments be used to generate and 

^13 interpret an ORM Specification 202 without being stored in memory 104. The ORM 

y 

lijl4 Grammar 200 of the present invention is particularly advantageous because it provides 

y 

iff 8 15 an extensible textual system in which it is very easy for the user to add new constructs 

; i 3 
\rssr 

16 for specifying mappings between the relational model and the object model. For 

17 example, one can easily add new rules to define mappings other that those provided in 

18 Figure 17. Such examples for extending the ORM Grammar 200, descriptions of their 

19 functionality and the API are provided in Appendix D. 

20 Referring again to Figure 2, the memory 104 is shown as including an ORM 

21 Specification 202. An ORM Specification 202 is a textual specification of an instance of 

22 object-relational mapping information based on the ORM Grammar 200. In other 
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1 words, the ORM Specification 202 defines how data is mapped from the object-oriented 

2 system to the relational system and vice versa. The present invention is particularly 

3 advantageous because of the use and structure of the ORM Specification 202. More 

4 specifically, the ORM Specification 202 is preferably a text file or ORM file, and specifies 

5 the mapping using the ORM Grammar 200 discussed above and shown in Figure 17. In 

6 the preferred embodiment, the ORM Specification 202 can be indexed or referred to by 

7 using an ORMID. Since the ORM Specification 202 is described textually, it can be 

8 stored easily in memory 104, a storage device 110 or even as part of a relational 

9 database. Furthermore, because the ORM Specification 202 is described textually there 
^10 is no special software required to create, view and edit the ORM Specification 202. Any 
niii one of a variety of text editor or graphical user interfaces can be used to create, modify 
^12 and review ORM Specifications 202. One such exemplary ORM Specification 202 is 
Q13 shown in Figure 18. 

hi 

J 14 The memory 104 also includes Object Class Definitions 204 that define an object 
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:ffl5 model. Object Class Definitions 204 describe an object model in an object-oriented 

16 language such as Java. The Object Class Definitions 204 describe the object model in a 

17 conventional manner such that objects are instances of classes. The Object Class 

18 Definitions 204 essentially define the object-oriented system and formatting for data 

19 that is transferred from or to the object-oriented system. One such exemplary set of 

20 Object Class Definitions 204 is graphically depicted in Figure 19, and the concept typical 

21 of such object models are described for the particular example in Appendix B. 
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1 



Also included in the memory 104 is a relational database management system 



2 (RDBMS) 206. The RDBMS 206 may be any one of a conventional type such as Oracle, 

3 Sybase, Informix, Microsoft SQL server, and IBM DB2. The RDBMS 206 preferably 

4 includes routines and modules for storing, retrieving and editing data maintained in a 

5 relational system such as may be present on the storage device 110 or distributed over 

6 the network and accessible via the network interface 112. 

7 The memory 104 also includes one or more operating systems 208. The 

8 operating system is preferably a conventional personal computer operating system such 

9 as UNIX, or DOS and Windows sold by Microsoft Corporation. Alternatively, the 

10 present invention could use other conventional operating systems such as OS/2 or 

11 System 8.0 for the Macintosh by Apple Computer. 

12 A Database Exchange Unit 210 is also included in the memory 104. The Database 

13 Exchange Unit 210 is the routine or module that controls the processor 102 to perform 

14 the actual exchange of data from the relational system to the object-oriented system. At 

15 the highest level, it includes programs and routines that operate to translate data from 

16 the object model to the relational model and vice versa. The Database Exchange Unit 

17 210 is initialized using an ORM Data Structure Creation Unit 302 as will be described in 

18 more detail below, and once initialized, operates independently using the OR Mapping 

19 Unit 304 to perform data and command translation. 

20 The Schema Generator 212 is also stored in memory 104. The Schema Generator 

21 212 is a tool or routines for controlling the processor 102 to generate the relational 

22 database schema (table definitions, constraint definitions) as well as metadata 




PATENT 



1 information corresponding to the Object Class Definitions 204 and the ORM Data 

2 Structures 308 during initialization. After the relational database schema have been 

3 created, they are stored in memory 104 or the RDBMS 206 and used by OR Mapping 

4 Unit 304 to map object calls to database requests. The Schema Generator 212 (e. g., 

5 JDXSchema in Java) is preferably invoked with the command: 

: — p Q | java JDXSchema [-metaCreate | -metalnit | -init] <ORMFile> 

7 This Schema Generator 212 takes the name of the file (e. g., abc.jdx) containing the 

8 Object-Relational Mapping information as input, and generates three script files 

9 containing the SQL DDL statements for creating the required tables and their primary 
=S5io keys (abc.jdx.create); foreign key constraints (abc.jdx. alter); and dropping those 

constraints and tables (abc.jdx. drop). Before using the database 206 for Object- 
or 12 Relational Mapping (for the very first time), the flag -metaCreate is used. This causes 
i;gl3 the ORMMetadata Tables 214 to be created in the database 206. These ORMMetadata 
!Ul4 Tables 214 are subsequently used to store the Object-Relational Mapping information. 
:^15 By using the flag -metainit one can store just the Object-Relational Mapping information 

16 (metadata) in the database 206 corresponding to a given ORMID. This is useful when 

17 the database tables for user objects do not need to be (re-) created. By using the flag - 

18 init, the above scripts are automatically executed against the database 206 such that the 

19 user can start creating and using persistent user objects against the database in Java 

20 programs. The flag -init also stores the Object-Relational Mapping information 

21 (metadata) in the database 206 corresponding to the given ORMID in <ORMFile>. 

22 Only one of the three options (metaCreate, metalnit, init) may be specified. 

-14- 
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1 



The memory 104 also includes RDBMS Tables and ORMMetadata Tables 214. 



2 The RDBMS Tables 214 basically define the relational model just as the Object Class 

3 Definitions 204 define the object model. In other words, the RDBMS Tables 214 set forth 

4 the organization and structure of the data in the relational model in addition to 

5 describing certain functionality provided by the relational model. The RDBMS Tables 

6 214 hold persistent data for the objects which are instances of the Object Class 

7 Definitions 204. 

8 The present invention also stores multiple ORM Specifications 202 in the 

9 ORMMetadata Tables 214 that are part of the database 206. The ORMMetadata Tables 
'^10 214 hold persistent data for the ORM Specification 202 and Named Sequence Generator 
fill 226. Most modern RDBMSs support a data type of LONGVARCHAR (e.g., 'text' in 
*^12 Sybase RDBMS) which can accommodate large textual data. Having a database table 
■3 13 ORMMetadata 214 with the following structure provides a convenient way to store the 
1Jl4 Object-Relational Mapping information. For example, the command 



18 can be used to store the ORM Specification 202 in the database 206, where the ORMId 

19 (defined below with reference to Figure 10) identifies the specification uniquely. The 

20 text of the ORM File goes into the Metalnfo field, and the MetaFileName field is 

21 initialized with the ORM File name for recording purpose. Even if the RDBMS 206 does 

22 not support a LONGVARCHAR style field, it is easy to store the Metalnfo text in 



CREATE TABLE ORMMetadata (ORMId varchar(80), Metalnfo 




LONGVARCHAR, MetaFileName varchar(80) CONSTRAINT 



17 



PK_ORMMetadata PRIMARY KEY (ORMId)); 




PATENT 



1 multiple rows of a separate table with a varchar(255) field and an ORMId field. The 

2 ORMId field has the same value for all the records holding chunks of Metalnfo for a 

3 particular ORMId. A time stamp field is preferably added to the ORMMetadata Tables 

4 214 to keep track of when the particular mapping information was created. A version 

5 field that identifies the version of the grammar describing the Object-Relational 

6 Mapping information stored in Metalnfo field is also included in the ORMMetadata 

7 Tables 214. The version information is employed to correct the interpreter for the 

8 specification because the ORM Grammar 200 of the specification may change to 

9 accommodate new functionality. 

10 Thus, the ORMMetadata Table 214 provides a very convenient facility to store 

11 multiple Object-Relational Mapping information, each identifiable uniquely through 

12 ORMIds. It also provides an elegant way of partitioning the object view of the 

13 underlying relational data. The ORMMetadata Tables 214 also include a table for 

14 storing sequence number information as will be described below with reference to the 

15 Named Sequence Generators 226. 

16 The memory 104 also includes applications 216 and a text editor or graphical 

17 user interface 218. The applications 216 may be any one of a conventional type written 

18 in object-oriented languages such as Java. The applications 216 are routines or modules 

19 that allow the user to access data in the system 100. Also included in memory 104 is a 

20 conventional text editor or graphical user interface 218. The text editor or graphical 

21 user interface 218 may be any one of a number of conventional editing interfaces. As 

22 noted above, since the ORM Specification 202 is a text file, any type of text editors or 




PATENT 



1 graphical user interfaces 218 may be included in the system 100, and thereby be used to 

2 change the ORM Specification 202 and thus how data and commands are exchanged 

3 between the relational system and the object-oriented system. 

4 The memory 104 also includes a Schema Reverse Engineering Unit 220. The 

5 Schema Reverse Engineering Unit 220 is a routine or tool for creating Object Class 

6 Definitions 204 and ORM Specification 202 using a database schema (table definitions, 

7 constraint definitions) for a set of tables. The Schema Reverse Engineering Unit 220 

8 provides the user, given a relational model, with the ability to generate the ORM 

9 Specification 202 for translating between the given relational model and an object- 

10 oriented model. The Schema Reverse Engineering Unit 220 also generates or defines 

11 the object-oriented model by creating the Object Class Definitions 204. The operation of 

12 the tools forming the Schema Reverse Engineering Unit 220 will be described in more 

13 detail below with reference to Figure 13. 

14 Also included in the memory 104 is an ORM Template Specification 222. The 

15 ORM Template Specification 222 is a module that is used in conjunction with the 

16 Schema Reverse Engineering Unit 220. The ORM Template Specification 222 provides 

17 data that along with information about the relational model is used by the Schema 

18 Reverse Engineering Unit 220 to produce the Object Class Definitions 204 and the ORM 

19 Specification 202. The ORM Template Specification 222 is a simplified ORM 

20 Specification 202 including the names of the tables to be considered for generating 

21 Object Class Definitions 204. The metadata information about named tables in the 

22 RDBMS 206 is used to create Object Class Definitions 204. 
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1 The memory 104 further includes a Metadata ORM Specification 224. The 

2 Metadata ORM Specification 224 is a specification like the ORM Specification 202 that 

3 can be used to generate data structures for the object relational mapping. In particular, 

4 the Metadata ORM Specification 224 is preferably a predefined ORM Specification 

5 describing the object-relational mapping between metadata objects and ORMMetadata 

6 Tables 214 which store information about ORM Specification 202 and Named Sequence 

7 Generators 226. 

8 Finally, the memory 104 includes Named Sequence Generators 226. Named 
< s * 9 Sequence Generators 226 are routines or modules that generate persistently unique 
plO sequence numbers. These unique sequence numbers are used in turn by the 

ffhl applications 216 to store unique objects in a database 206. Since the numbers are 

~ 12 persistently unique, this ensures that old or existing objects will have different 

Si 

q13 identification numbers. In the present invention, there is a unique declarative method 

y 

!U 14 for specifying named sequences, and the Named Sequence Generators 226 manage and 

1^15 control the use and creation of sequence numbers to ensure that there are no conflicts 

16 with existing sequence or identification number for objects, even among different 

17 applications. The present invention is advantageous because like the Grammar 200, the 

18 Named Sequence Generators 226 provide a declarative way of defining named 

19 sequences that can be used to generate persistently unique sequence numbers in an 

20 efficient way. These sequence numbers, among other things, can be used to assign 

21 unique ids to different objects. The Named Sequence Generators 226 of the present 

22 invention are particularly advantageous for a number of reasons. First, the grammar 
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1 for specifying sequence generators is simple and intuitive. Second, the declarative way 

2 of specifying the sequences is a compatible and convenient way of defining sequences 

3 along with Object Relational Mapping information. Third, the way sequences are 

4 named by the Named Sequence Generators 226 is done in a manner convenient for 

5 application programmers because it uses meaningful names (e. g., imageldSequences) 

6 for the sequence generators, and allows the creation of multiple sequence number 

7 domains (e. g., parti dSequences, customerldSequences, etc.). Fourth, the Named 

8 Sequence Generators 226 allow the user to specify a starting value for a sequence 

9 generator. This is very advantageous because for already existing data with a home- 

10 grown way of generating sequence numbers, the new method may be employed with a 

11 starting value of 1 more than the maximum value in the current set of data; and from 

12 problem domain or business needs a starting value other than 1 may be more 

13 appropriate such as when a new company starts its invoice numbers from 1001 or when 

14 4 billion starts are already identified and documented and a new application for 

15 creating entries for new starts may use a sequence generator with a starting value of 4 

16 billion and 1. Finally, the declaration of a sequence is database independent, and the 

17 sequence generator implementation mechanism can work with any backend relational 

18 database. 

19 Also included with the Named Sequence Generators 226 are routines, 

20 specifically, an API (getNextSequence) to get the next set of persistence sequence 

21 numbers. The feature of specifying an increment in the API call of getNextSequence 

22 enables an efficient generation of sequence numbers without requiring a database call 
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1 for every new sequence number. The calling application can safely assume that no 

2 other application would get the next sequence number in the range of the returned 

3 sequence number n to n+increment-1 (both inclusive). The method for servicing the 

4 API is described below in more detail with reference to Figure 22. 

5 Referring now to Figure 3, the present invention is best shown as being the 

6 coupling element between a relational system and an object-oriented system. In normal 

7 operation, the Database Exchange Unit 210 controls the transfer of data and commands 

8 between an application 216 (object-oriented system) and the RDBMS 206 (relational 

9 system). The Database Exchange Unit 210 is coupled to receive and send data and 
;^10 commands to and from the application 216 using conventional object-oriented 

I 

yill techniques, such as constructs provided by an OOP language such as Java. The 

'"j 12 Database Exchange Unit 210 formats and structures the data and commands into and 

j^l3 from a format suitable for an object-oriented system. Similarly, the Database Exchange 

11J14 Unit 210 is coupled to the RDBMS 206 to receive and send data and commands to and 

15 from the RDBMS 206 in a format suitable for relational systems. More particularly, the 

16 Database Exchange Unit 210 generates queries, inserts, updates and deletions, to fetch 

17 or modify the data in the RDBMS 206 based on the object calls received from the 

18 application 216. The Database Exchange Unit 210 is also coupled to the Object Class 

19 Definitions 204 and the ORM Specification 202. The Database Exchange Unit 210 

20 interacts with the Object Class Definitions 204 during both initialization and normal 

21 operation to perform the exchange of data and commands between the application 216 

22 and the RDBMS 206. The Database Exchange Unit 210 is also coupled to the ORM 
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1 Specification 202, but only interacts with the ORM Specification 202 as will be described 

2 in more detail below with reference to Figures 5 and Figure 11. 

3 Referring now to Figure 4, the Database Exchange Unit 210 is shown in more 

4 detail. The Database Exchange Unit 210 preferably comprises an Object Call Processing 

5 Unit 300, an ORM Data Structure Creation Unit 302, an OR, Mapping Unit 304, a 

6 Database Interface Unit 306, and an ORM Data Structures 308. Each unit 300, 302, 304, 

7 306 and 308 is preferably a routine or module stored in a block of memory 104 for 

8 controlling the processor 102 to perform the operations as will be described below. The 

9 units 300, 302, 304, 306 and 308 are coupled by bus 114 as shown, and their operation, 

■Is 17 

\ 

mlO. exchange of data and functionality will be described below with reference to Figure 5. 

r 

mil Those skilled in the art will recognize that while the memory blocks are shown as 

"",.\ 

]il2 separate 300, 302, 304, 306 and 308, and coupled to each other and other components by 

e; 

I=3l3 the bus 114, they can easily comprise different regions of a contiguous space in memory 

y 

1U14 104. 

y 

!;f'l5 The operation of the Database Exchange Unit 210 and its components is best 

16 shown in Figure 5. Figure 5 is a block diagram of Database Exchange Unit 210 

17 constructed as modules and showing the coupling utilized by their functionality. In 

18 Figure 5, the couplings used for the transfer of data for initialization and the creation of 

19 the ORM Data Structures308 are shown by dashed lines for ease of understanding. As 

20 noted above, the Database Exchange Unit 210 is delineated in Figure 5 by a dashed 

21 block and comprises an Object Call Processing Unit 300, an ORM Data Structure 

22 Creation Unit 302, an OR Mapping Unit 304, a Database Interface Unit 306, and an 
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1 ORM Data Structures 308. The Object Class Definitions 204 and the ORM Specification 

2 202 are stored in another portion of memory as has been described above with reference 

3 to Figure 2. 

4 The ORM Data Structures 308 are in-memory data structures built from the ORM 

5 Specification 202 and Object Class Definitions 204. The ORM Data Structures 308 are 

6 used in the translating of object calls to relational data and commands. More 

7 specifically, the ORM Data Structures 308 preferably include the following data 

8 structures to store various information about the object-relational mapping: 



.0 



•sir 
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Columnlnfo 


Stores the relational column information - name, SQL type etc. 


Tableinfo 


Stores the tableName, the list of Columnlnfo corresponding to 
its columns etc. 


Attriblnfo 


Stores the following information about a class attribute: name, 
type, Columnlnfo etc. 


ComplexAttriblnfo 


In addition to Attriblnfo information, it also stores the 
information about the referenced object (or collection), the 
referencing attributes, the containment of the referenced object 
etc. 


ReferenceKeylnfo 


Stores information about the primary and reference keys of a 
class. 


Classlnfo 


Stores the className, reference to Tableinfo, list of Attriblnfo, 
list of ComplexAttriblnfo, etc. 


CollectionClasssInfo 


In addition to Classlnfo information for its element class, it also 
stores the information about collection type, containment type 
and order by attributes, etc. 


Databaselnfo 


Stores url, ORMId, list of Classlnfo, list of Tableinfo, list of 
database connections, etc. 



10 The ORM Data Structure Creation Unit 302 is preferably coupled to the Object 

11 Class Definitions 204 and the ORM Specification 202 to receive the object model and the 
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1 mapping between the relational system and the object-oriented system, respectively. 

2 The ORM Data Structure Creation Unit 302 is also coupled to the Database Interface 

3 Unit 306 for accessing the RDBMS 206 to receive schema that describe how the 

4 relational system organizes data. Using this information, the ORM Data Structure 

5 Creation Unit 302 generates the ORM Data Structures 308. The ORM Data Structure 

6 Creation Unit 302 is preferably routines or tools to generate the ORM Data Structures 

7 308 using an ORM Specification 202 (coming from either an ORM file or Metainfo in the 

8 ORMMetadata Tables 214 ) and Object Class Definitions 204. In one embodiment, the 

9 ORM Data Structure Creation Unit 302 parses the ORM Specification 202 as per the - 

CJ 

^10 ORM Grammar 200 specified and builds the ORM Data Structures 308. Each construct 

Pll of the ORM Grammar 200 is used to create the data structures. For example, each 

212 <CLASS-SPEC> creates an instance of Classlnfo. Each <COLLECTION-CLASS-SPEC> 

2: 

f nl3 creates an instance of CollectionClassInfo. The reflection facility of the language may be 

IUl4 used to create the instances of Attriblnfo. <PRIMARY-KEY-SPEC> and < REFERENCE- 

;gl5 KEY-SPEO are used to create instances of ReferenceKeylnfo. < RELATIONSHIP- 

16 SPEC> is used to create the instances of <ComplexAttribInfo>. Once the internal data 

17 structures have been built using data from the ORM Specification 202, each class is fully 

18 understood in terms of its different components and how they can be stored and 

19 retrieved using the Object Class Definitions 204. Next, the ORM Data Structure 

20 Creation Unit 302 retrieves user objects of these classes and generates appropriate SQL 

21 statements to insert, update or delete various components of those objects. If objects 

22 need to be retrieved, the top-level objects are retrieved first (based on an optional search 
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1 condition) and then their complex attributes are initialized after fetching the 

2 appropriate referenced objects as per the mapping information. 

3 The remaining portions of the Database Exchange Unit 210, in addition to the 

4 ORM Data Structures 308, are used for the actual transfer of data and commands from 

5 the object-oriented system to the relational system, and vice versa. The Object Call 

6 Processing Unit 300 is coupled by line 250 to the application 216 to receive object- 

7 oriented commands/ calls and data from the application 216. The Object Call 

8 Processing Unit 300 is also coupled to the OR Mapping Unit 304. The Object Call 

: ^ 9 Processing Unit 300 receives calls and begins the translation of the object calls so that 

fklO they can be executed on the relational system. More particularly, the Object Call 

Hpll Processing Unit 300 intercepts Application Programming Interface (API) level calls for 

^12 object manipulation (query, insert, update, delete etc.) and executes those using OR 

pl3 Mapping Unit 304. Furthermore, a set of exemplary API calls which the Object Call 

c : \ 

njl4 Processing Unit 300 is responsive to are shown in Appendix C. 

y 

:^15 The OR Mapping Unit 304 is coupled to the Object Class Definitions 204, the 

16 ORM Data Structures 308, the Database Interface Unit 306, in addition to the Object Call 

17 Processing Unit 300. The OR Mapping Unit 304 is preferably routines or tools for 

18 performing the object-relational mapping using the ORM Data Structures 308, user 

19 objects (from the Object Class Definitions 204) and relational data (from the Database 

20 Interface Unit 306). The operation of the OR Mapping Unit 304 is described in more 

21 detail below with reference to Figures 14A and 14B. It should be noted that the 

22 Database Interface Unit 306 is used by the OR Mapping Unit 304 to access data from the 
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1 relational database. The Schema Generator 212 may optionally use the Database 

2 Exchange Unit 210 to initialize the ORMMetadata Tables 214 with ORM Specification 

3 202 and Named Sequence Generators 228. 

4 Referring now to Figure 6, a block diagram of a first embodiment of the Schema 

5 Generator 212 is shown. For convenience and ease of understanding, like reference 

6 numerals have been used to reference like parts. Furthermore, while shown and 

7 described below as being included as part of the Schema Generator 212 in this 

8 embodiment, certain modules such as the ORM Data Structure Creation Unit 302, ORM 
,^ 9 Data Structures 308 and Database Interface Unit 306 could alternatively be part of the 
plO Database Exchange Unit 210 as described above, and omitted from the Schema 

13**11 Generator 212. In such an embodiment, the ORM Data Structure Creation Unit 302, 

~12 ORM Data Structures 308 and Database Interface Unit 306 in the Database Exchange 

Bi 

□13 Unit 210 would be used by the Schema Generator 212. 

a . a 

! lSl4 The Schema Generator 212 preferably comprises the ORM Data Structure 

~15 Creation Unit 302, the ORM Data Structures 308, the Database Interface Unit 306, a 

16 Relational Schema Statements Generation Unit 602, Script Files Containing Relational 

17 Schema Statements 604 and a Relational Schema Statements Application Unit 606. Each 

18 unit 302, 306, 308, 602, 604 and 606 is preferably a routine or file stored in a block of 

19 memory 104 for controlling the processor 102 to perform the operations as will be 

20 described below. The ORM Specification (an ORMFile) 202 may be used to create the 

21 database schema, and this is done by the Schema Generator 212. The tables in the 

22 schema are preferably used to hold the data for the class objects. The units 302, 306, 308, 
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1 602, 604 and 606 are coupled by bus 114 as shown, and their operation and functionality 

2 will be described below with reference to Figure 7. 

3 Figure 7 is a block diagram of a second embodiment of the Schema Generator 212 

4 constructed as modules. The operation of the Schema Generator 212 can best be 

5 understood by reference to the operation according to Figure 7. As shown in Figure 7, 

6 the ORM Data Structure Creation Unit 302 is coupled to the Object Class Definitions 

7 204, the ORM Specification 202 and the Metadata ORM Specification 224. The Object 

8 Class Definitions 204, the ORM Specification 202 and the Metadata ORM Specification 

9 224 are preferably stored in another portion of memory 104 as has been described above 
T^lO with reference to Figure 2. The ORM Data Structure Creation Unit 302 uses the Object 
ijlll Class Definitions 204 and either the ORM Specification 202 or the Metadata ORM 

'^12 Specification 224 to generate an ORM Data Structures 308 as has been described above 

jU s 13 with reference to Figure 5. The ORM Data Structures 308 created for Metadata ORM 

jl J14 Specification 224 can be used to store ORM Specification 202 and Named Sequence 

yJ 

•Sis Generators 226 as information in ORMMetadata Tables 214. The ORM Data Structures 

16 308 has a format and content as described above. The ORM Data Structures 308 is 

17 coupled as an input to the Relational Schema Statements Generation Unit 602. The 

18 Relational Schema Statements Generation Unit 602 is a routine or tools to produce 

19 statements that will produce the relational schema in the RBDMS 206. Using the 

20 information about the schema for the relational system contained in the ORM Data 

21 Structures 308, the Relational Schema Statements Generation Unit 602 produces the 

22 Script Files Containing Relational Schema Statements 604. The operation of the 
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1 Relational Schema Statements Generation Unit 602 is described in more detail below 

2 with reference to Figure 12. The output of the Relational Schema Statements Generation 

3 Unit 602 is coupled to the input of the Relational Schema Statements Application Unit 

4 606 to provide the Script Files Containing Relational Schema Statements 604 produced 

5 by the Relational Schema Statements Generation Unit 602. The Relational Schema 

6 Statements Application Unit 606 is also coupled to the Database Interface Unit 306 and 

7 applies the commands necessary to produce the schema in the database with the table 

8 names and definitions. More particularly, the Relational Schema Statements 

9 Application Unit 606 through the Database Interface Unit 306 issues the commands 

O 

[fjlO from Script Files Containing Relational Schema Statements 604 to the RDBMS 206. 
pll Referring now to Figure 8, a block diagram of a first embodiment of the Schema 

^12 Reverse Engineering Unit 220 is shown. As noted above, the Schema Reverse 

I«,13 Engineering Unit 220 is a tool to create an ORM Specification 202 and Object Class 

I 5 

=i'=F 

IU14 Definitions 204 given a database schema. Again, for convenience and ease of 

y 

;:*15 understanding, like reference numerals have been used to reference like parts, and 

16 while shown and described below as being included as part of the Schema Reverse 

17 Engineering Unit 220 in this embodiment, certain modules such as the ORM Data 

18 Structures 308 and Database Interface Unit 306 could alternatively be part of the 

19 Database Exchange Unit 210 as described above. In such an alternate embodiment, the 

20 Schema Reverse Engineering Unit 220 uses the ORM Data Structures 308 and Database 

21 Interface Unit 306 in the Database Exchange Unit 210. The Schema Reverse Engineering 

22 Unit 220 preferably comprises the Database Interface Unit 306, the ORM Data 
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1 Structures 308, the Object Class Definitions Generation Unit 802, the ORM Specification 

2 Generation Unit 804, the Database Metadata Inquiry Unit 806 and the Reverse 

3 Engineering ORM Structure Creation Unit 808. These modules 306, 308, 802, 804, 806, 

4 808 are preferably routines stored in memory 104 and coupled by bus 114. 

5 Referring now to Figure 9, a block diagram of a second embodiment of the 

6 Schema Reverse Engineering Unit 220 is shown. The ORM Template Specification 222 

7 is a simplified ORM Specification with the names of tables to be considered or used for 

8 generating Object Class Definitions 204 and is provided to the Reverse Engineering 

9 ORM Structure Creation Unit 808. The Reverse Engineering ORM Structure Creation 
JfrjlO Unit 808 is also coupled to the RDBMS 206 (not shown in Figure 9) by the Database 
fjill Metadata Inquiry Unit 806 and the Database Interface Unit 306. The Database Metadata 

12 Inquiry Unit 806 accesses the RDBMS 206 using the Database Interface Unit 306 to 

5 3 2 
'SIS' 

^13 retrieve metadata including the schema for the relational model and information about 

ji J14 the object model. The Database Metadata Inquiry Unit 806 provides the metadata to the 

a. e 

Jf3l5 Reverse Engineering ORM Structure Creation Unit 808. The Reverse Engineering ORM 

16 Structure Creation Unit 808 receives the ORM Template Specification 222. The ORM 

17 template information contains the names of the tables to be used for generating Object 

18 Class Definitions 204. The Reverse Engineering ORM Structure Creation Unit 808 uses 

19 the basic ORM template information along with the metadata to produce ORM Data 

20 Structures 308. The ORM Data Structures 308 is in turn used by the Object Class 

21 Definitions Generation Unit 802 and the ORM Specification Generation Unit 804 to 

22 produce the Object Class Definitions 204 and the ORM Specification 202, respectively. 

2^ * 
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1 The operation of the components of the Reverse Engineering ORM Structure Creation 

2 Unit 808 is described in more detail with reference to Figure 13 below. 

3 One advantage of the present invention is that the structure of the ORM 

4 Specification 202 provides a very convenient way of experimenting with an Object- 

5 Relational Mapping. Since the ORM Specification 202 is stored as a text file, and the 

6 Database Exchange Unit 210 can be easily generated from the ORM Specification 202, 

7 the user can continue to refine and use the ORM Specification 202 until the user is 

8 satisfied with the results of Object-Relational Mapping. Furthermore, after the user is 

0 9 satisfied with the ORM Specification 202, the present invention stores this information 
%10 at a common place such that many other applications or instances of the same 

application running on different machines can utilize this information. More 

'- J 12 specifically, the present invention stores it in the ORMMetadata Tables 214 that are part 

P 

1 j 13 of the database 206. 

y 

ijjl4 Referring now to Figure 10, a flow chart of the preferred process for generating 

m 

15 ORM Data Structures 308 according to the present invention from an ORM Id or ORM 

16 Specification (ORM file) 202 is shown. Each ORM specification 202 for mapping object 

17 classes into relational data is uniquely identified in the present invention by an object- 

18 relational mapping identification name (ORMId). An ORMId defines a view of objects 

19 over a set of tables. There may be multiple such views (overlapping or non- 
20 overlapping) identified by different ORMIds on the same database. ORMIds help in 
21 partitioning the relational data into different object spaces. The application 216 just 
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1 needs to deal with only the relevant partition instead of worrying about all the tables 

2 and all the different classes defined using those tables. The ORMId is preferably part of 

3 the <DATABASE-URL> defined in Appendix B. 

4 With the present invention, the user is able to indicate that a specific file should 

5 be used to determine the mapping between the object model and the relational model. 

6 The user must either specify a particular file by providing an ORM file or provide an 

7 identification to an existing ORM Specification 202 stored in the database 206. 

8 Otherwise a default ORM Id for a default ORM Specification 202 stored in the database 
l *( 9 206 will be used. The process begins with step 1000 by determining whether an ORM 
1=10 file has been specified. If an ORM file has been specified, then the method proceeds to 
Sill step 1002 where the process is set to use the ORM file specified. This is done by setting 

* u 12 the variable ORMFileName to the specified file. After step 1002, the method proceeds 

□ 

ljjl3 to step 1004 where the method uses the ORM Specification 202 corresponding to the 

Ujl4 ORMFileName to create an ORM Data Structures 308. The operations performed by the 

sO 

"'15 system 100 in step 1004 will be provided in more detail below with reference to Figure 

16 11. After step 1004, the process is complete and ends. On the other hand, if in step 

17 1000, an ORM file was not specified, then the method continues to step 1006. In step 

18 1006, the method determines whether an ORM identification (Id) has been specified. If 

19 an ORM Id has been specified, method continues in step 1008 and uses the given ORM 

20 Id to set the variable ORMID. If an ORM Id has not been specified, the method 

21 continues in step 1010, and uses a default ORM Id to set the variable ORMID. For 

22 example, the default ORM Id is the string "defaultORMId".- After either step 1008 or 
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1 step 1010 the method proceeds to step 1012. In step 1012, for the variable ORMID, the 

2 method extracts Metainfo from the database table, ORMMetadata Tables 214, into a 

3 local file. Then in step 1014, the method sets the variable ORMFileName to the name of 

4 the local file created in step 1012. After step 1014, the method proceeds to step 1004 and 

5 creates the ORM Data Structures 308 as has been described above. As can be seen from 

6 steps 1000 to 1014, the method of the present invention is particularly advantageous 

7 because by providing the system 100 with an ORM file, or an ORM Id or just using the 

8 default ORM Id, the system 100 can generate the ORM Data Structures 308 which 

^ 9 specifies the mapping between the relational model and the object-oriented model. This 

plO is particularly advantageous because it allows the translation between the Object- 
s' 

Bill oriented model and relational model to be stored in a persistent manner either within 

'"'■4 

T12 the database 206, on the network (not shown) and accessed via the network interface 

fil3 112, or in any one of a number of storage devices 110 coupled to the system 100. 

y 

I Ul4 When an object-oriented application program 216 wants to use a particular 

15 Object-Relational Mapping specification, it just has to specify the corresponding 

16 ORMId. Then it is a matter of retrieving the Metainfo into a temporary file and using 

17 the process described above with reference to Figure 10 to provide Object-Relational 

18 Mapping functionality. With some optional cleverness, a character stream may be 

19 realized over the Metainfo field and the creation of a temporary file may be avoided. 

20 Even after permanently storing the Object-Relational Mapping information in the 

21 database 206, it may be possible to override that by specifying <ORMFile> clause in the 

22 <DATABASE-SPEC>. This gives a very innovative way of doing program 
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1 development and refinement. The old programs continue to work with the stored 

2 specification while the new development may be happening with the new specifications 

3 in local text files. 

4 Referring now to Figure 11, a flow chart of the preferred process for generating 

5 the ORM Data Structures 308 according the present invention using an ORM 

6 Specification 202 and Object Class Definitions 204 is shown. This method corresponds 

7 to step 1004 of Figure 10, and includes the steps necessary to create instances of each of 

8 the ORM Data Structures 308. Each of these ORM Data Structures 308 has been defined 
^ 9 above in the discussion of Figure 2. The method begins in step 1102 by creating an 
s=Jl0 instance of Databaselnfo. Next in step 1104, the method continues by creating an 

ffhl instance of Tablelnfo and Classlnfo for each class specification. Then the method 

"is 
'i I 

jzfl2 continues by creating an instance of CollectionClassInfo for each collection specification. 

ci 

pl3 Then in step 1108, the method creates the instances of Attribinfo for each Classlnfo. 

y 

f1Jl4 Next in step 1110, the process uses any SQL map specification to override the default 

2^15 mappings between the columns and attributes. Then in step 1112, the method uses 

16 Primary-Key and Reference-Key specifications to create instances of ReferenceKeyinfo. 

17 The method continues in step 1114, by using the relationship specification to create 

18 instances of ComplexAttributelnfo. Then in step 1116 the system 100 retrieves 

19 Metadata from the database 206 to enhance Tablelnfo with instances of Columnlnfo. 

20 Next in step 1118, the method matches Attributelnfo with Columnlnfo. Then after step 

21 1118, the method in step 1120 generates SQL statements for each class using the 

22 instances of Tablelnfo and Columnlnfo. Finally, in step 1122, the system 100 generates 
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1 insert and update statements in parameterized form after which the process ends. 

2 Referring now to Figure 12, a flow chart of the preferred process for generating 

3 relational schema from an ORM Specification 202 and Object Class Definitions 204 is 

4 shown. As indicated Figure 12, the preferred process for generating relational schema 

5 includes many of the same process steps described above with reference to Figure 11 for 

6 the process of generating the ORM Data Structures 308. For convenience and ease of 

7 understanding, like reference numerals are used to indicate like steps including steps 

8 1102 through 1114 which are preferably identical to the steps described above with 

9 reference to Figure 11. Thus, the preferred method for generating relational schema 
1^10 from the ORM Specification 202 and the Object Class Definitions 204 begins by 

gill performing steps 1102 through 1114. However, after step 1114, the method of Figure 12 

^12 continues in step 1202. In step 1202, the method adds Columnlnfo in Tablelnfo for each 

13 13 primitive and embedded attribute of each Classlnfo. Then in step 1204, the system 100 

3 . S 

14 generates a create table statement and primary key constraint statement in a CREATE 

:J* 5 15 file for each Tablelnfo. Next in step 1206, the method generates unique key and 

16 referential key constraint statements in an ALTER file for each Classlnfo. Then in step 

17 1208, the method generates alter table drop constraint statements and drop table 

18 statements in a DROP file for each Classlnfo. Finally in step 1210, the method executes 

19 the CREATE, ALTER and DROP files to modify the database 206. 

20 Referring now to Figure 13, a flow chart of the preferred process for generating 

21 an ORM Specification 202 and Object Class Definitions 204 from a database schema is 

22 shown. The process for generating an ORM Specification 202 begins in step 1302 by 
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1 creating an instance of Databaselnfo. The method continues in step 1304 by creating an 

2 instance of Classlnfo and Tablelnfo for each class in the ORM Template Specification 

3 222. The method then proceeds to step 1306 where a metadata query and creation of 

4 Columnlnfo and Attributelnfo in the corresponding Classlnfo are performed for each 

5 instance of Tablelnfo. Next in step 1308, the system 100 performs a metadata query to 

6 get the PrimaryKeylnfo for each Classlnfo. Then in step 1310, the method performs the 

7 metadata query to get the foreign key information and creates the corresponding 

8 ComplexAttributelnfo for each instance of Classlnfo. Then in step 1312, the method 
^ 9 continues for each Classlnfo by generating the Object Class Definitions 204 using the 

■ise: 

plO Attributelnfo and ComplexAttributelnfo. Finally, in step 1314, an ORM Specification 

_j= 

Bill 202 is created using the Databaselnfo and all the instances of Classlnfo. 

^12 Referring now to Figures 14A and 14B, a flow chart of a preferred process for 

pl3 responding to an object call using the OR Mapping Unit 304 generated from the ORM 

!Ul4 Specification 202 is shown. The process begins in step 1402 with the system 100 testing 

hi 

:^15 whether an object call received through the Object Call Processing Unit 300 is a query. 

16 If the object call tested in step 1402 is determined to be a query, the method continues in 

17 step 1404. In step 1404, the method sets up the access planned data structure according 

18 to the query flags and query details in order to access referenced objects. Then in step 

19 1406, the system 100 retrieves the base SELECT statement from Classlnfo. Next in step 

20 1408, the method tests whether any predicate has been specified. If a predicate has been 

21 specified, the method continues from step 1408 to step 1410 before proceeding to step 

22 1412. In step 1410, the method, in particular the OR Mapping Unit 304, translates the 
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1 specified predicate and appends the predicate as a WHERE clause. If a predicate has 

2 not been specified, the method continues directly from step 1408 to step 1412. In step of 

3 1412, the SELECT statement including a WHERE clause, if any, produced by steps 1406 

4 through 1410 is issued against the database 206. Next, the method continues in step 

5 1414 by determining whether more rows are available from the database 206. If more 

6 rows are available from the database 206, the method continues in step 1416. 

7 Otherwise, the method proceeds to step 1424 and tests whether there are query objects 

8 from the subclasses. If there are additional query objects from the subclasses, the 
jaa 9 method returns to step 1406 to process the objects of subclasses. If there are not 
1=310 additional query objects from subclasses, then the method continues in step 1426 as will 



□ 13 database 206, then the method continues to step 1416. In step 1416, the system 100 

y 

&yi4 fetches the next row and creates an instance of a top-level object. Then in step 1418, the 



:^15 system 100 sets the attribute values from the corresponding column values. Then in 

16 step 1420, the method creates the required foreign key entries and associates them with 

17 target class structures. After step 1420, the method continues in step 1422 to determine 

18 whether the specified number of top-level objects have been created. If the method 

19 determines that the specified number of top-level objects have not been created, then 

20 the method continues back to step 1414 and loops through steps 1416 to 1420 until a 

21 top-level object is created for each row in the database 206. On the other hand, if the 

22 method determines that the specified number of top-level objects have been created, 




be described below. 



£12 



If in step 1414, the process determined that more rows are available from the 
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1 then the method continues in step 1426. As shown in Figure 14B, the method continues 

2 with step 1426 by creating a SELECT statement and a WHERE clause using the foreign 

3 keys for each referenced target class. After step 1426, the method retrieves rows, creates 

4 target objects and links them with the referencing complex attributes in step 1428. Then 

5 in step 1430, the method creates a foreign key entry for each complex attribute of the 

6 target class before proceeding to step 1432. In step 1432, the method tests whether there 

7 are more foreign keys for target classes. If there are, the method returns to step 1428 

8 and performs both step 1428 and 1430 for each foreign key. If it is determined in step 
^ 9 1432 that there are no more foreign keys for the target class, the method proceeds to 

'-.11 

===ao step 1434. In step 1434, the method returns the list of top-level objects to the user and 

AH 

lltll then the method ends. 

^12 Referring back to Figure 14A, if the object call tested in step 1402 is determined 

m 

ql3 not to be a query, then the method assumes that it is an insert object call and proceeds 

!Ul4 to step 1440. Those skilled in the art will recognize that the present invention described 

jhj 

:f;fl5 in Figures 14A and 14B could be modified to handle updates and deletes in a similar 

16 fashion. In step 1440, the method sets up an access plan data structure as per insert 

17 flags and insert details for the accessing referenced objects. Next in step 1442, the 

18 method retrieves the INSERT statement from Classlnfo. In step 1444, the preferred 

19 process prepares an INSERT statement for the current connection to the database 206. 

20 Then in step 1446, the method finds its value and binds it with the column position for 

21 each Attriblnfo. Next in step 1448, the process executes the INSERT statement to store 

22 the top-level objects. Finally, in step 1450 the method determines whether there are 
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1 more non-null referenced objects to be inserted. If there are more non-null referenced 

2 objects to be inserted, the method returns to step 1442 to create an INSERT statement 

3 for each of them. If there are not any more non-null referenced objects, the processing 

4 of the insert object call is complete. 

5 Referring now to Figure 15, the novel and unique method for performing objects 

6 streaming will be described. As shown in Figure 15, the process begins with step 1502 

7 by beginning a new transaction. Next in step 1504, the system 100 generates a query 

8 call to the Database Exchange Unit 210 for a plurality of objects with the streaming flag. 

9 The number of objects is preferably defined as n, and those skilled in the art will 
1=310 understand that the number of objects may be any number of objects that the user 
GPll desires. Next in step 1506, the system 100 determines a query context (QC) for 

Jl2 streaming. Then in step 1508, the system 100 invokes the query operation on the query 

5; 

□ 13 context for a predetermined number (X) of objects. In step 1510, the method opens and 

e : : 

I 1 J 14 saves in the query context the query cursor for the table of top-level class objects. Then 

Iff 15 in step 1512 the system 100 initiates the query processing to fetch the predetermined 

16 number (X) of objects. This is done by performing steps 1404 through 1434 as has been 

17 described above with reference to Figure 14. Then in step 1514, the query context is 

18 saved for this session of the Database Exchange Unit 210, and the objects are returned in 

19 step 1516. Next in step 1518 the objects are processed. In step 1520, the user may decide 

20 to get more objects through the current stream of objects. If the user does not want to 

21 get more objects through streaming, the method is moved to step 1522 by creating a 

22 "query close" call to the Database Exchange Unit 210. Then in step 1524, the saved 
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1 query cursor and query context are released. Finally, in step 1526, the "query close" call 

2 finishes and in step 1528 the transaction is committed to the database 206. If it is 

3 determined in step 1520 that the user decides to get more objects from the stream, then 

4 the preferred method proceeds through steps 1530 through 1538. In step 1530, the 

5 process generates a "query fetch" call for a second preferred number (m) of objects to 

6 the Database Exchange Unit 210. Next in step 1532, the process of the present invention 

7 invokes the query fetch operation on the saved query context for the second 

8 predetermined number of objects. In step 1534, the query cursor saved in the query 

^ 9 context is retrieved for use. Then in step 1536, the query is processed to fetch m objects. 

,^10 Again, this step is identical to step 1512 and is done by performing steps 1404 to 1434. 

Dill After step 1538, all of the m objects are returned and the process returns to step 1518 to 

^12 process the m returned objects. After step 1518, the user may continue to use the stream 

'if j 

J^13 of objects iteratively as described earlier until the whole stream is exhausted or the user 

W 

njl4 does not need any more objects. 



16 a query operation is shown. This was described in the context of performing the step of 

17 creating the required foreign key entry and associating it with the target class structures 

18 from Figure 14A. Those skilled in the art will recognize that while the method for using 

19 directed operations is described here in the context of query operation, directed 

20 operations may be applied to insert, update and delete operations in a similar fashion. 

21 As shown in Figure 16, the sub-process begins in step 1604 by determining whether or 

22 not there are more complex attributes. If there are no more complex attributes, the 




Referring now to Figure 16, a preferred method for using directed operations for 
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1 method is complete and continues onto step 1422 without any directed operations. 

2 However, if there are more complex attributes, then the method continues instead to 

3 1606. In step 1606, the method determines whether this attribute of the class needs to be 

4 accessed as per the plan data structure. If in step 1606, the method determines that this 

5 attribute of the class does not need to be accessed according to the plan data structure 

6 then the process moves to step 1610 where the complex attribute is ignored before 

7 returning to step 1604. Otherwise, a foreign key entry is created and associated with 

8 the target class structure in step 1608 before the method returns to step 1604. This way 
^ 9 the foreign key entries are made only for those complex attributes which need to be 

plO accessed as per the plan data specified by the user. 

uhl Referring now to Figures 20A-20D, block diagrams of various embodiments for 

^12 architectural configurations of the present invention in different tiers (parts) of 

|«|13 applications using different relational database management systems 206 are shown. In 

y 

1 1 Jl4 the exemplary embodiments shown below, the Database Exchange Unit 210 is 
U 

"ffl5 preferably implemented in Java. Thus a variety of other embodiments will be 

16 understood to those skilled in the art. 

17 Figure 20A shows a stand alone application 2000 which is using the Database 

18 Exchange Unit 210, that is preferably a class libraries which execute as part of the 

19 application process in the same Java Virtual Machine Process (VMP). This mode may 

20 be useful during prototyping or simple applications. The same application can easily be 

21 split into 2 tiers with the Database Exchange Unit 210 providing the second tier. This is 

22 similar to how the Database Exchange Unit 210 has been described above. 
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1 Figure 20B shows a CORBA/RMI application server 2004 which is using 

2 Database Exchange Unit 210 as class libraries that execute as part of the application 

3 server process in the same Java VM. The server 2004 is serving multiple clients 2002a, 

4 2002b, 2002c, 2002d, and is using multiple back end RDBMSs 206a, 206b, 206c, and 206d. 

5 Figure 20C shows multiple applications 216a, 216b, 216c attached to one Java 

6 Exchange server 2006 that is providing a multithreaded database exchange service for 

7 one RDBMS 206. 

8 Figure 20D shows multiple applications 216a, 216b, 216c, 216d, 216e, 216f of 
^ 9 which are attached to two different Database Exchange Units 210a, 210b that are 

^10 providing database exchange services for multiple RDBMS 206a, 206b, 206c, 206d of 

Hill different types. The Database Exchange Units 210a, 210b may be distributed over many 

^12 machines to provide scalability. They may be co-located with an RDBMS 206 on the 

r il3 same machine (e.g., Database Exchange Unit 210b and Oracle RDBMS above) for 

Hjl4 improved data transfer. 

^15 Figures 21 A-21B are graphic block diagrams of architectural configurations 

16 without and with the present invention. These Figures 21 A-21B show the advantage of 

17 the present invention. Figure 21 A shows the prior art where the database exchange 

18 units require hand coding to map the Java objects to existing RDBMSs. However, with 

19 the present invention all the hand coding is eliminated. With the simple declaration of 

20 the desired mappings between the object model and the relational model, the database 

21 exchange unit is automatically generated. Furthermore, the Database Exchange Unit 
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1 can be generated from an ORM Specification or reverse engineered from object models 

2 and relational schema. 

3 Referring now to Figures 22A and 22B, flow charts of the preferred process for 

4 generating Named Sequence Generators 226 and using them to produce persistent 

5 object identification numbers are shown. As has been noted above, the Named 

6 Sequence Generators 226 preferably include an application program interface (API) for 

7 retrieving sequence numbers. For example, the API in Java is 

8 ^ "public long getNext Sequence (String sequenceName, long 

9 ^ increment) throws RemoteException, JDXException, " 

^10 In response, Named Sequence Generators 226 return the next available sequence 

Hill number for the given 'sequenceName 7 . The persistent sequence number in the 

K '2 12 database 206 is incremented by 'increment 7 such that the calling application can safely 

pl3 assume that no other application would get the next sequence number in the range of 

|1J14 (returned sequence number n, n+increment-1) both inclusive. In other words, this 

*B 15 range (n, n+increment-1) presents a unique set of numbers with respect to the given 

16 sequenceName across all applications accessing the same RDBMS 206. These sequence 

17 numbers can typically be used to assign unique ids to different objects. 

18 As shown in Figures 22A and 22B, the process has two portions: an initialization 

19 portion (design-time portion) and an execution portion (run-time portion). While the 

20 two portions of the process are shown and will be described as being performed in a 

21 linear manner, those skilled in the art will recognize that there may be a significant 

22 delay between performing initialization and performing execution. The initialization 
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1 ' process begins in step 2202 during schema generation as has been described above. 

2 During schema generation, the process creates a metadata table "jdxSequence" in the 

3 database 206. The metadata table "jdxSequence" preferably has the following format 

4 CREATE TABLE jdxSequence(seqName varchar(80), startingValue INT, jdxORMId 

5 varchar(80), maxlncrement INT, nextValue INT, CONSTRAINT JDX_PK_jdxSequence 

6 PRIMARY KEY (jdxORMId, seqName)). In other words, the method creates a table that 

7 indicates a sequence name, a starting value, a next value and an increment, along with 

8 other information. Next in step 2204, for each sequence generator defined in the 
ASA 9 <SEQUENCE-SPEC> the method creates an entry in the table jdxSequence. Once 

f jlO complete, the table identifies which sequence generators are available, and the rows in 

ffhl the table can be used for the generation of unique identification numbers, and this 

~?12 portion of the method is complete. 

£3 13 During execution, the method begins in step 2206 by receiving an object call to 

y 

!ui4 produce a new object or sequence id number. During runtime at the application level, a 

Irs? 
\ ITS 

;J^15 need often arises to get a range of unique sequence numbers (could be only one) such as 



16 to assign unique id numbers for new objects. Then in step 2208 the method receives a 

17 get next sequence number call from the application 216. Then in step 2210, the method 

18 starts an independent transaction for the given name sequence. Then in step 2212, the 

19 method increments the value of nextValue column with the given "increment" value for 

20 the sequence name. The method then commits the independent transaction to the 

21 database 206 in step 2214. In response in step 2216, the database 206 returns the value n 

22 which equals next value minus the increment. Finally, in step 2218, the application 216 




PATENT 



1 uses the range of numbers generated by the system 100 at the application level. For 

2 example, the unique sequence ID name can be produced using the sequence name and 

3 the returned values. 

4 While the present invention has been described with reference to certain 

5 preferred embodiments, those skilled in the art will recognize that various 

6 modifications may be provided. These and other variations upon and modifications to 

7 the preferred embodiments are provided for by the present invention. 
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